Aller au contenu principal

Pourquoi le standard Transparent Proxy pour les Fabriques et Registres ?

1. ERC-1967 : Prévenir les collisions de stockage​

L’implémentation du Transparent Proxy suit EIP-1967, qui standardise la manière dont les proxys stockent l’adresse du contrat d’implémentation.

  • Sans standard : Chaque projet pourrait utiliser des emplacements de stockage arbitraires, et la mise à jour ou la composition de contrats pourrait entraîner des collisions de stockage, corrompant les variables d’état.
  • Avec ERC-1967 : L’adresse de l’implémentation est toujours stockée dans un emplacement de stockage déterministe (bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)). Cela évite les collisions, rend la disposition du stockage prévisible et permet aux outils de s’appuyer sur une convention partagée.

2. Visibilité sur les explorateurs de blocs​

Comme ERC-1967 est un standard largement reconnu, les explorateurs de blocs (tels qu’Etherscan, Basescan et Polygonscan) le détectent automatiquement.

  • Ils affichent le lien entre le contrat proxy (avec lequel les utilisateurs interagissent) et le contrat d’implémentation (où réside la logique).
  • Cette transparence permet à notre communauté de vérifier quel code est exécuté et assure la confiance dans les mises à jour.
  • Les développeurs et auditeurs en bénéficient, car ils peuvent inspecter le contrat d’implémentation exact derrière chaque proxy.

3. Transparent vs. UUPS et autres modèles​

Lors du choix d’un modèle de proxy, nous avons comparé le Transparent Proxy au UUPS (EIP-1822) et à d’autres approches d’évolutivité.

  • Avantages du Transparent Proxy

    • Maturité : Transparent Proxy est le modèle le plus largement adopté et audité. Il est utilisé depuis des années dans les protocoles DeFi, les DAO et les registres.
    • Éprouvé : De nombreux contrats critiques en production l’utilisent, démontrant sa fiabilité dans des conditions réelles.
    • Fonctionnalité d’upgrade immuable : Le mécanisme de mise à jour est intégré dans le proxy lui-même et ne peut pas être remplacé ou compromis par de futurs contrats d’implémentation. Cela évite la désactivation accidentelle ou malveillante des mises à jour.
    • Expérience développeur : Il est simple pour les constructeurs — les administrateurs utilisent le proxy admin pour les mises à jour, tandis que les utilisateurs interagissent uniquement avec la logique d’implémentation.

  • Pourquoi pas UUPS ?

    • Les proxys UUPS exigent que la logique de mise à jour réside dans le contrat d’implémentation. Mal gérée, cette approche peut introduire des risques (par ex. perte de la capacité de mettre à jour si la fonction correspondante est supprimée ou défectueuse).
    • Bien que plus légers en consommation de gaz, le compromis est une plus grande responsabilité pour les développeurs afin d’éviter les erreurs.

Compte tenu de notre besoin de stabilité et de fiabilité à long terme pour les contrats de registre, le Transparent Proxy était le choix évident.

4. Pourquoi différent des Diamonds​

  • Pour les contrats de registre, nous privilégions maturité, visibilité et sécurité — Transparent Proxy est parfaitement adapté.
  • Pour les contrats Garden (comptes multi-fonctionnalités), nous utilisons le Diamond Standard (EIP-2535), qui prend en charge une logique modulaire et extensible.
  • Chaque choix correspond à son objectif : Transparent Proxy pour la stabilité et la clarté, Diamonds pour la flexibilité et la composabilité.

5. Références​